<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!-- 

This work is licensed under the Creative Commons Attribution 3.0 Unported License. 
To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ 
or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

-->

<html xmlns="http://www.w3.org/1999/xhtml">

<!--
START META-DATA 
-->
<head>
<title>Timeboxing: An Introduction</title>
<!-- metadata -->
<meta name="generator" content="S5" />
<meta name="version" content="S5 1.2a2" />
<meta name="author" content="Robert Burrell Donkin http://robertburrelldonkin.name" />
<meta name="company" content="OpenTalkWare" />

<!-- configuration parameters -->
<meta name="defaultView" content="slideshow" />
<meta name="controlVis" content="hidden" />

<!-- style sheet links -->
<link rel="stylesheet" href="ui/default/slides.css" type="text/css" media="projection" id="slideProj" />
<link rel="stylesheet" href="ui/default/outline.css" type="text/css" media="screen" id="outlineStyle" />
<link rel="stylesheet" href="ui/default/print.css" type="text/css" media="print" id="slidePrint" />
<link rel="stylesheet" href="ui/default/opera.css" type="text/css" media="projection" id="operaFix" />

<!-- embedded styles -->
<style type="text/css" media="all">

</style>

<!-- S5 JS -->
<script src="ui/default/slides.js" type="text/javascript"></script>

</head>
<!--
END META-DATA 
-->



<body>

<!--
START COMMON LAYOUT
-->
<div class="layout">
<div id="controls"><!-- DO NOT EDIT --></div>
<div id="currentSlide"><!-- DO NOT EDIT --></div>
<div id="header"></div>
<div id="footer">
<h1>Timeboxing: An Introduction</h1>
<h2><a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
<img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/80x15.png" />
</a>
&#8226; 
<a rel="tag" href="http://www.opentalkware.org/">
<img alt="OpenTalkWare" style="border-width:0" src="logo/opentalkware.png" />
</a>
</h2>
</div>
</div>
<!--
END COMMON LAYOUT
-->



<div class="presentation">


<!--
START PREFACE
-->
<div class="slide">
<h1>Timeboxing</h1>
<h2>An Introduction</h2>
<!-- 
START OPEN CONTENT ONLY
Derivative works which are not open content should remove the follow 
-->
<h4>This is <a href="http://www.opentalkware.org/" rel="external">OpenTalkWare</a></h4>
<!-- 
END OPEN CONTENT ONLY
-->

<div class="handout">
<!-- 
Document license
-->
<h4>License</h4>
<p>
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
<img alt="CC-BY" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/80x15.png" /></a>
This work is licensed under the Creative Commons Attribution 3.0 Unported License.
</p>

<h4>Attribution</h4>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
<p>
Based on
<span xmlns:dc="http://purl.org/dc/elements/1.1/" 
  href="http://purl.org/dc/dcmitype/Text" 
  property="dc:title" rel="dc:type">http://opentalkware.googlecode.com/svn/talk/Timeboxing/</span> 
  by 
<a xmlns:cc="http://creativecommons.org/ns#" 
  href="http://www.opentalkware.org" 
  property="cc:attributionName" 
  rel="cc:attributionURL">OpenTalkWare</a>
  The original source available
  from <a 
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    href="http://opentalkware.googlecode.com/svn/talk/" rel="dc:source">OpenTalkWare</a>
    is licensed under the
    <a rel="license" href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 Unported License</a>.
The original uses <a href='http://meyerweb.com/eric/tools/s5/'>S5</a> which is public domain. Please see the
<a href='http://www.meyerweb.com/eric/tools/s5/credits.html'>credits</a> for information about all the wonderful and 
talented contributors to S5!
</p>
<!-- 
END ATTRIBUTION
-->


<!--
ABSTRACT 
-->
<h4>Summary</h4>
  <p>
Introduces the concept of timeboxing in the context of Agile development.
  </p>
<h4>Abstract</h4>
  <p>
TODO:
  </p>
</div>

<div class='notes'>
  <ul>
    <li>
      TODO:
    </li>
  </ul>
</div>
</div>
<!--
END PREFACE
-->









<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>What Is A Timebox?</h1>
<ul class='incremental'>
<li>A fixed time period alloted for an activity</li>
</ul>

<div class='handout'>
  <p>
What is a time box?

A time box fixes the time allowed for an activity.

Examples: A lightning talk timeboxed to 10 minutes. A retrospective might be to 1 hour. An iteration to 1 week. A sprint to 3 months. 

When the time allows for more 
  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<img src='orthodox-triangle.png'></img>

<div class='handout'>
  <p>

Software Economics

Conventional constraint triangle.

Reasons: in software, the consequences in terms of throughput when changing resources, quality and time are unpredicatable and non-linear.

* Labour is not interchangable
* Communication drag often increases faster than output when adding developers, and this cost is paid by everyone. Productivity scales poorly with increased team size.
* The relationship between human resources and output is non-linear. In some cases, adding resources reduces output.
* Low quality software has a complex relationship with costs. When production quality is too low, future productivity will be effected by the need to rework by fixing bugs. 

  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>This Triangle Fails</h1>
<ul>
<li>for software, </li>
<li>the relationship is complex and non-linear.
<ul class='incremental'>
<li>Labour is not interchangable</li>
<li>Productivity scales poorly with increased team size</li>
<li>Low quality work impacts future productivity</li>
<li>Adding developers may reduce throughput</li>
</ul>
</li>
</ul>

<div class='handout'>
  <p>

Software Economics

Conventional constraint triangle.

Reasons: in software, the consequences in terms of throughput when changing resources, quality and time are unpredicatable and non-linear.

* Labour is not interchangable
* Communication drag often increases faster than output when adding developers, and this cost is paid by everyone. Productivity scales poorly with increased team size.
* The relationship between human resources and output is non-linear. In some cases, adding resources reduces output.
* Low quality software has a complex relationship with costs. When production quality is too low, future productivity will be effected by the need to rework by fixing bugs. 

  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">

<img src='agile-triangle.png'></img>


<div class='handout'>
  <p>
Agile triangle.
  </p>
  <blockquote cite='http://www.agilemanifesto.org'>
  Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.  
  </blockquote>
    <blockquote cite='http://www.agilemanifesto.org'>
Principles behind the Agile Manifesto


We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. 
  </blockquote>
  
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Timeboxing</h1>
<ul class='incremental'>
<li>Timebox, don't scopebox.</li>
<li>Plan to adapt...</li>
<li>by iterating timeboxes</li>
<li>and always working on the most important features</li>
<li>of the moment.</li>
</ul>

<div class='handout'>
  <p>
  TODO:
  Foo bar blah
  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Timeboxing Creates A Rhythm </h1>
<ul class='incremental'>
<li>Marks progress without micromanagement.</li>
<li>Separates long and short term needs.</li>
</ul>

<div class='handout'>
  <p>

Timeboxing plans a project as a sequence of time boxes, setting a rhythmic beat. 
Timeboxing separately control, review, reflection, performance, training 
and so on is beneficial for flow and ensures that activities conducive to the long term 
health of a project are not sacrificed for short term gain.

Example: think about the drummer in a band, or the conductor in an orchestra. 
This rythym organically facilitates creativity without micromanagement

  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Regular Timeboxing</h1>
<ul>
<li>Estimating software is tricky.</li>
<li>Regular timeboxing allows empirical feedback.</li>
<li>Velocity measures progress per timebox
<ul class='incremental'>
<li>As the project progresses</li>
<li>evidence accumulates</li>
<li>and estimates improve.</li>
</ul>
</li>
</ul>

<div class='handout'>
  <p>
Software productivity is complex and non-linear. Labour is not interchangable, 
and the relationship between individual and team productivity is complex.
Blending a team is an unpredictable art. 
  </p><p>
Orthodox estimation techniques used in project planning typically break down a complex
project into a series of small tasks. Given high variance but unbiased estimates (in a 
statistical sense) over a long project estimation errors will balance to zero.
  </p><p>
Unfortunately, these statistical qualities are unusual in software estimates. The 
statistics required to plan software projects goes beyond hoping errors sun to zero.
</p><p>
For example, estimates
are provisional on the current state of knowledge, which is almost always incomplete.
If missing information impacts a project, it is almost always in highly negative way. 
So, to model software estimates Guassians must be skewed or estimates will be biased.  
  </p>
Timeboxing allows an empirical alternative: velocity. For each iteration, measure progress.
Every iteration, use this data to estimate future progress.  
  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Continuous Improvement</h1>
<ul class='incremental'>
<li>Inductive learning</li>
<li>Empirical experimentation</li>
<li>Reducing waste</li>
</ul>

<div class='handout'>
  <p>
Keep Iterations Short

Inductive learning is powerful: people find it fun and easy to learn this way[1]. 

[1] Providing that the culture is right. A positive culture of continuous improvement, 
driving quality and customer satisifaction ever higher. If you have a negative culture "the blame game", 
that weaker individuals will be targeted and blamed for poor performance. So when dealing. 

Group psychology has it's down side, as well. 


Remember this: often the rate of improvement is highest in the early days of learning a new skill. 
Progressing from compedency to mastery is a long and difficult road. If performance is judged on a team 
basis then it is in the best interests of masters to work with apprentices.  
  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->












<!--  
START OF ACKNOWLEDGEMENTS 
-->
<div class="slide">
<h1>Thanks</h1>
<ul>
<li>For listening.</li>
<li>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
<p>
Based on
<cite>Timeboxing: An Introduction</cite>
  by 
<a href="http://www.opentalkware.org" >OpenTalkWare</a>.
 Original source is <a href="http://opentalkware.googlecode.com/svn/talk/" rel="dc:source">available</a> under
    <a rel="license" href="http://creativecommons.org/licenses/by/3.0/">CC-BY</a>. UI based on 
    <a href='http://www.meyerweb.com/eric/tools/s5/credits.html'>S5</a> which is public domain.
</p>
<!-- 
END ATTRIBUTION
-->
</li>
</ul>

<div class='handout'>
  <p>
  TODO:
  Foo bar blah
  </p>
  <p>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
  <a href="http://www.opentalkware.org" >OpenTalkWare</a> contributors to <cite>Timeboxing: An Introduction</cite> 
  include Robert Burrell Donkin http://robertburrelldonkin.name
<!-- 
END ATTRIBUTION
-->
  </p>
</div>

<div class="notes">
 <ul>
  <li>TODO:</li>
  <li>TODO:</li>
 </ul>
</div>
</div>
<!--  
END OF ACKNOWLEDGEMENTS
-->









</div>

</body>
</html>
